Columbia Kermit/kermit.zip/newsgroups/misc.19950528-19950726/[e-mail]_Sat Jun 17 15:55:58 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17812
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Sat, 17 Jun 1995 11:56:03 -0400
Received: by apakabar.cc.columbia.edu id AA13272
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 17 Jun 1995 11:56:02 -0400
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Ckermit for Unix and VTKeys
Date: 17 Jun 1995 15:55:58 GMT
Organization: Columbia University, New York City
Lines: 68
Message-Id: <3rutue$[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: [e-mail]

In article <[e-mail]>,
 <[e-mail]> wrote:
>I using Ckermit with Linux, and CKermit is not sending the correct key
>strings for PF1 and PF2. I looked in the manual it just said make sure that
>the correct emulation is in effect, and the have the key assignments
>correct for VT300 emulation in the X-Term session.
>
>Of intereset when using "show key" the only the first part of the key
>string is shown in the case of PF1 only \27 the other part is on the next
>line with the Ckermit prompt.
>
>Is it possible to use VT key emulation in a connect session with Ckermit
>for Unix (I'm using Linux).
>
Time to add this one to the FAQ.

C-Kermit comes in basically two varieties:

 . The version for OS/2 that had direct access to the keyboard and screen,
   and therefore can see keyboard scan codes and so on, and can do true
   terminal emulation.  Here you have comprehensive key mapping ability.

 . The versions for UNIX, VMS, and so on, that do not have direct access
   to the keyboard and screen, and rely on your console driver, terminal
   window, external terminal emulator (such as MS-DOS Kermit), or actual
   terminal to perform the terminal functions.

UNIX is an interesting case.  Traditionally, UNIX was accessed through a
terminal that was plugged into a terminal port on a timesharing system.
Thus, there *is* no keyboard and screen -- just a communication port.  In
recent years, this type of access has been largely replaced by terminal
servers, but there is still no keyboard and screen.  However, now that we
have a plethora of PC-based UNIX varieties that run on workstations (PCs)
that actually *do* have a keyboard and screen, it would seem to make sense
that Kermit should be able to see all the keys.

Unfortunately, this is not the case.  Most varieties of UNIX do not let
the application see the keyboard.  There is no kernel function called "get
keyboard scan code".  There is only read(), and read() reads a character,
not a multibyte scan code.  Thus, even if your console driver has
programmed (say) your F1 key to send (say) ESC O P, Kermit will read three
characters in succession, as if they were three keystrokes, not one.  It
has no way of knowing that you pressed the F1 key.  As far Kermit knows,
you pressed the Esc key, then the O key, then the P key.

Now perhaps Linux *does* have a system call to let an application at the
keyboard.  But...

 (a) In what contexts does it work?  Only on the raw console?  In an xterm
     window?  etc etc.

 (b) Does it require special privilege to execute?

 (c) What about all the other versions of UNIX that run on PCs -- FreeBSD,
     SCO, Solaris/Intel, etc etc?

 (d) What about all the other versions of UNIX that run on non-PC
     workstations -- SunOS, Solaris/Sparc, HP-UX, AIX, SGI, etc?

So the answer is, for now at least -- and as the documentation states --
C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only
for keys that generate a single 8-bit value, 0..255.  Other types of
mappings will have to be accomplished outside of Kermit by configuring
your console driver, your xterm (e.g. with Xmodmap), and so on.

I'll add this to FAQ.

- Frank